Device verification system and method

ABSTRACT

There is provided a method and system for verifying a device, having components. Identification numbers of the components are read and then verified. The process of verifying comprises matching each identification number in a database to determine whether each identification number is valid. In one embodiment, the database is remote from the device, wherein verification is performed over a network connecting a database server containing the database with the device. The device transmits the identification numbers for each of the components to the database server for verification. A file allocation structure reader may be located in a basic input/output system of the device for reading and verifying data files from a persistent storage media without loading an operating system. The device may comprise a gaming machine that contains a monitor for monitoring one or more system events being processed by the gaming machine. The monitor monitors routine and non-routine events. A detector is included for detecting selected system events so that they may be recorded.

BACKGROUND OF THE INVENTION

[0001] This invention relates generally to a method and apparatus forverifying and detecting errors in a device and, more particularly, forverifying the device before starting or continuing operation, and formonitoring and logging events that may occur in the device.

[0002] In common practice in the prior art, for example in the gamingmachine field, verification of a device may occur by testing the entirecontents of a read only memory (ROM) containing the application softwarefor the device to ensure that tampering has not occurred, for example,after a prize is won during game play. An abbreviated bit string iscomputed from the gaming application program and stored in a secure ROMthat is separate from the ROM where the gaming application is storedbefore deployment of the gaming machine. When the gaming machine isstarted, or at times when verification is desired, for example, after awin occurs during game play, a verification program calculates anotherabbreviated bit string from the contents of the ROM wherein the gamingapplication program is stored, and the previously computed abbreviatedbit string stored in the secure ROM is used with the newly calculatedabbreviated bit string to verify the gaming application program.

[0003] Such a verification system may be adequate where the media onwhich the gaming application is stored is read-only, and thereforedifficult to alter, and where there is little danger that the othercomponents of the device can be compromised to breach security, such asa casino with 24 hour surveillance. However, such constant surveillanceis not always available, both inside and outside the gaming industry,and as technology advances, it becomes more difficult to rely on thesesafeguards. The shortcomings of prior systems become more prevalent whenseveral devices are connected over a network.

[0004] Accordingly, there has been a long existing need for enhancedverification of devices, and more enhanced self-critical analysis oftheir components other than just the application software.

SUMMARY OF THE INVENTION

[0005] Briefly, and in general terms, the present invention provides animproved method and system for verifying a device, having components,before or during use.

[0006] More particularly, by way of example and not necessarily by wayof limitation, the present invention provides a system and method forverifying a device by verifying the components of that device. Thecomponents may comprise, for example, software components, firmwarecomponents, hardware components, or structural components of anelectronic device. These components include, without limitation,processors, persistent storage media, volatile storage media, randomaccess memories, read-only memories (ROMs), erasable programmable ROMs,data files (which are any collections of data, including executableprograms in binary or script form, and the information those programsoperate upon), device cabinets (housings) or cathode ray tubes (CRTs).Identification numbers or strings of the components are read and thenverified. The process of verifying may comprise matching eachidentification number in a database to determine whether eachidentification number is valid. In the case where a data file comprisesone of a plurality of operating system files, verification of that file,in effect, comprises verifying part of an operating system. For datafiles, the file names may comprise the identification numbers.

[0007] The database may comprise a relational database, object database,or may be stored in XML format, or in a number of other formats that arecommonly known. However, in the case where storage space is limited forthe verification system, a flat file structure for the database may bemore desirable, and require less software instructions to read andretrieve information from. The database may also comprise an independentsystem stack of bindings, which comprise numbers, identification stringsor signatures in the database for matching or authenticating thecomponents, from manufacturers of the components, each identificationnumber being verified using the binding from the manufacturer of therespective component to verify the component. Especially in the contextof smaller devices such as personal digital assistants (PDAs), such asystem stack may comprise a subset of one or more global componentdatabases containing bindings from manufacturers of the components, eachbinding of the subset being associated with at least one of theidentification numbers of one of the components in the device. Providingsuch a limited subset helps control the size of the verification systemby controlling the size of the database. Another example of averification system in which it may be desirable to limit the size ofthe database is one in which the database is stored in a personalcomputer's (PC's) complementary metal oxide semiconductor memory (CMOS),along with other configuration settings for the PC. Storing the databasein the CMOS may improve security wherein the PC may be configured suchthat only users with administrative passwords may change the content ofthe portion of the CMOS containing the database.

[0008] Structural components, such as cabinets, may contain anelectronic identification chip embedded within them, such as a so-calledDallas chip or an IBUTTON device manufactured by Dallas Semiconductor ofDallas, Tex. These devices allow a unique identifier, placed within asemiconductor or chip, to be placed on a component that may or may notbe electronic, such as a computer or gaming machine cabinet. The IBUTTONdevice is a computer chip enclosed in a 16 mm stainless steel can. Thesteel button can be mounted, preferably permanently or semi-permanently,on or in the structural component. Two wires may be affixed to theIBUTTON device, one on the top, and one on the bottom, to exchange databetween the IBUTTON device and a processor, serial port, universalserial bus (USB) port, or parallel port.

[0009] The matching process may comprise matching each identificationnumber based on the type of component that the identification numberidentifies. The identification number and the type of component ismatched in the database in order to verify that the identificationnumber is valid. The reading of the identification numbers and verifyingthe components may be performed at the time of start-up of the device,or periodically during operation of the device. Operation of the devicemay be stopped if any one of the identification numbers is not matchedin the database. In the case of a game or gaming machine type of device,a tilt condition message is generated if any one of the identificationnumbers is not matched in the database.

[0010] The database may consist of a set of signatures, also calledbindings. At least with respect to the components that comprise datafiles or firmware, a well-known hash function, the Secure HashFunction-1, also known as SHA-1, may be used to compute a 160-bit hashvalue from the data file or firmware contents. This 160-bit hash value,also called an abbreviated bit string, is then processed to create asignature of the game data using an equally well-known, one-way, privatesignature key technique, the Digital Signature Algorithm (DSA). The DSAuses a private key of a private key/public key pair, and randomly orpseudorandomly generated integers, to produce a 320-bit signature of the160-bit hash value of the data file or firmware contents. This signatureis stored in the database in addition to the identification number.

[0011] Either contained in the device, or attachable to the device, is aprocessor and a memory containing executable instructions or a softwareprogram file for verification of the components (verification software),which may itself be one of the components to verify. The verificationsoftware may be stored on a persistent storage media such as a hard diskdevice, read only memory (ROM), electrically erasable programmableread-only memory (EEPROM), in the aforementioned CMOS memory,battery-backed random access memory, flash memory or other type ofpersistent memory. Preferably, the verification software is stored in abasic input/output system (BIOS) on a solid-state persistent memorydevice or chip. BIOS chips have been used for storing verificationsoftware, such as the BIOS+ chip used by Bally Gaming Systems, Inc. ofLas Vegas, Nev. in their EVO gaming system. Placing the verificationsoftware in the BIOS is advantages because the code in the BIOS isusually the first code executed upon boot or start-up of the device,making it hard to bypass the verification process.

[0012] Alternatively, the verification software may be stored in afirmware hub, which may comprise the part of an electronic device orcomputer that stores BIOS information. In personal computer hubtechnology, such as that manufactured by the Intel Corporation of SantaClara, Calif., a hub is used in place of a peripheral componentinterconnect (PCI) bus to connect elements of chipsets.

[0013] The persistent storage media may be a removable storage unit suchas a CD-ROM reader, a WORM device, a CD-RW device, a floppy disk device,a removable hard disk device, a ZIP disk device, a JAZZ disk device, aDVD device, a removable flash memory device, or a hard card device.However, the database is preferably stored in a non-removable, securedevice either within the device being verified, or remotely on a server,in order to enhance security.

[0014] The verification software executes a DSA verification of the datafiles and firmware components. Also stored in the database is the publickey of the private key/public key pair. For each data file and firmwarecomponent, as part of the DSA verification, the processor andverification software first computes the hash value of the digitalcontents of the component using the SHA-1 algorithm. The verificationsoftware then processes or authenticates this computed hash value, usingthe DSA signature verification algorithm, which also takes, as input,the aforementioned public key stored in the database. The verificationpart of the DSA produces a boolean result (yes or no) as to whether theinputs solve the algorithm. If the algorithm is not solved by theinputs, then an unexpected result is produced, thereby failing to verifythe particular component. This may cause a fault tilt to occur toprohibit the loading operation of the device. Otherwise, use of thedevice is permitted. A detailed description of the DSA can be found inthe U.S. government's Federal Information Processing StandardsPublication (FIPS) 186-2. That publication describes each step of theDSA signature generation and verification.

[0015] Alternatively, the set of executable instructions may use theRivest-Shamir-Adleman (RSA) algorithm to verify the components. Usingthe RSA algorithm, a first abbreviated bit string or hash value iscomputed from each component's digital contents and encrypted into adigital signature. The digital signature is stored in the database alongwith the identification number for the component. When the device isverified, the component is verified by computing a second abbreviatedbit string computed from the component's digital contents. The signatureis retrieved from the database by searching the database for theidentification number. The signature is decrypted to recover the firstabbreviated bit string. The component is then verified by comparing thesecond abbreviated bit string with the first abbreviated bit string. Ifthe first and second abbreviated bit strings do not match, then thecomponent is not verified. As discussed below, this may cause a faulttilt to occur to prohibit the loading operation of the device.Otherwise, use of the device is permitted.

[0016] Instead of creating a digital signature for, or signing, eachdata file individually, collections of data files may be signed togetherin order speed up processing. The abbreviated bit strings, hash values,or signatures, also called digests, of the collection of data files arecollected into a catalog file, and the catalog is signed as describedabove.

[0017] In some cases, it may be desirable to nevertheless allowoperation of a device even though a data file failed verification. Forexample, that data file may contain an error caused by a number ofevents, such as a bad sector on a hard disk, which in turn caused thefailed verification of that data file. The failed verification isevidently not due to tampering of the device as the system of thepresent invention is generally designed to prevent. Still, operation ofthe device is not desirable unless and until the error in the data fileis corrected. When the data file is stored in alterable media,correcting such an error may be as simple as replacing the file. Alongwith the identification number, and encrypted signature or abbreviatedbit string, a valid replacement data file may also be stored in thedatabase. If the software program determines that the cause of theinvalid file is simply due to an error in the file, and not tampering,then the replacement file is pulled from the database to replace thedata file that failed the validation. A number of factors may be used bythe software program to make such a determination. For example,determination may be based on the number of data files or componentsthat fail validation. This may indicate a deceptive replacement of ahard disk in the device.

[0018] In one embodiment, the database is remote from the device,wherein verification is performed over a network connecting a databaseserver containing the database with the device. The device transmits theidentification numbers for each of the components to the databaseserver. The database server then performs the step of matching. Forexample, the device may be a personal computer (PC), with verificationbeing performed before a transaction is allowed on a network server. Aprime example of such a system is one set up for performing bankingtransactions with a network server owned or operated by a bank. In sucha system, a bank may only allow trusted transactions using an authorizedPC whose bindings for all of the components and banking transactionsoftware have been recorded in the database located on the bank'snetwork server, or another remote network server that is accessed by thePC. Once all of the components have been verified, the bank's networkserver then allows transactions to take place using the PC.

[0019] In another example, the device comprises a gaming machine,wherein the verification of the gaming machine is performed before gameplay is allowed on the gaming machine. The database may either belocated in a secure location in the gaming machine, such as a ROM deviceenclosed in a lock box within the gaming machine, or remotely from thegaming machine so that the gaming machine connects to a network servercontaining the database over a network. As with the banking personalcomputer described above, the components of the gaming machine areverified at the network server after the gaming machine transmits theidentification numbers, hash values, etc., to the network server.

[0020] Another aspect of the present invention is a method and systemfor recording event messages in a gaming machine. The device maycomprise a gaming machine which contains a monitor for monitoring one ormore system events being processed by the gaming machine. The operatingsystem of the gaming machine is event driven. In an event driven systemor device, applications and components respond to input from the user(mouse movement, keystrokes, menu choices, etc.) and messages from otherapplications and components. This is in contrast to, for example, abatch operation that continuously processes the next item from a groupof instructions. The monitor comprises an event management system, whichcomprises software or firmware that monitors components of the device.Alternatively, the monitor may be located on a remote server,workstation or other network device. The monitor, which may comprisehardware and software components such as a processor and eventmanagement software, monitors routine and non-routine events. As anexample, a coin insertion into a gaming machine will trigger acorresponding routine coin-in event message that triggers components tooperate and/or software instructions to execute. Similarly, an exceptionfault or divide by zero condition will trigger a non-routine or errorevent message to be generated for example. These event messages can begenerally referred to as system events.

[0021] Either included within the monitor, or separately but in closecoordination with the monitor, is a detector for detecting selectedsystem events of the one or more system events so that they may berecorded. The gaming machine, or the remote server monitoring the gamingmachine, stores the event message for the detected system event in a logfile.

[0022] Each monitored system event has a system event type. The detectorselects the selected system event based on the system event type for theselected system event. The system event type may be a code in the eventmessage that indicates a category of events that occur in the systemthat the system event belongs to. For example, the previously mentionedcoin-in, exception fault and divide by zero system events are each soidentified with the system event type. The detector selects the selectedsystem event by comparing the system event type for each monitoredsystem event to a list of system event types, and selecting one of themonitored system events for the selected system event if the systemevent type for the selected one monitored system event matches one ofthe system event types in the list. Each system event is monitored andas the detector selects a plurality of system events based on theirtypes, the system event messages for each selected system event arestored in a log file. The list may be stored in an index or lookup fileon a persistent storage media of one of the alterable types describedabove. The lookup file may comprise a database file, which may berelational, object based or in XML format for example. The log file mayalso be stored on a persistent storage media.

[0023] A buffer region of a memory may be set aside for buffering aplurality of the monitored system events, wherein the step of storingcomprises storing one or more of the buffered system events in the logfile with the selected one of the system events each time one of thesystem event types is detected by the detector. Preferably, the buffershould be large enough so that at least the last 1000 system events maybe stored in the buffer, and then written if a selected system event isdetected and stored. The buffer is thus operated as a first-in-first-outstack of system event messages.

[0024] Other digital contents of memory or components in the device maybe stored upon detection of a selected system event. For example, it maybe desirable to store the entire contents of a memory component,selected contents of a memory component, or selected or entire valuesfor registers of a processor component of the gaming machine. Forexample, if a selected system event is a memory protection exceptionerror, then it may be desirable to store at least the contents of theprotected memory that was violated and the memory allocation tables forthe offending application(s) that caused the error. Even if the memoryin which the protection exception error occurred comprises a safe orbattery-backed random access memory device, it nevertheless still may bedesirable to store the contents in case other applications shouldfurther modify the memory.

[0025] As another aspect of the present invention, it is desirable toperform operations on data files, such as verification operations, suchdata files being stored on a persistent storage media such as a harddisk, before or without the need for loading of the operating system foran electronic device. Typically, the operating system must be started orbooted in order to perform file access operations on the storage media.This is because the operating system usually exclusively contains thefile access system used to read the file allocation structure stored onthe storage media. However, in some devices, it would be desirable tovalidate data files on the storage media before booting the operatingsystem for, among other reasons, security purposes.

[0026] In this regard, the system of the present invention has a fileallocation reader stored in the basic input/output system (BIOS) orfirmware hub (FWH). This makes accessing files stored in the persistentstorage media or device possible in the absence of a running operatingsystem. The processor may access the file allocation reader in the BIOSto open the file allocation structure on the persistent storage mediaand to read it. For faster access, the processor may move the contentsof the file allocation structure into a RAM. The processor may thenprocess the file allocation structure to or provide access to filesstored on the persistent storage device.

[0027] Providing this functionality in the BIOS or FWH facilitatesaccessing the files stored in the storage device using a computerprogram stored in the basic input/output system wherein the computerprogram comprises a set of executable instructions for processing thefile allocation structure. An example of such a computer program thatmay benefit from this new functionality in the BIOS or FWH is theverification program described above for verifying software componentson the persistent storage media. In that case, operating system filesmay be verified, and this providing of access to files stored on thestorage media through the BIOS allows such verification to take placebefore the operating system is booted, or before any software program isrun from the storage media. This makes the verification softwarecompletely independent of files stored on the persistent storage mediathat are being verified.

[0028] As described above, verifying the data files may compriseverifying each data file by retrieving a first abbreviated bit stringcomputed from the file from the database, computing a second abbreviatedbit string from the data file, and verifying the file by authenticatingthe second abbreviated bit string using the first abbreviated bitstring. As described above, the database of signatures or abbreviatedbit strings may be stored in the BIOS as well, wherein the verificationsoftware uses DSA or RSA to verify each data file against thecorresponding signature or abbreviated bit string stored in thedatabase. The file allocation reader in the BIOS or FWH may beconfigured to read a 32-bit based file allocation table, a 16-bit basedfile allocation table, a WINDOWS NT file system structure, or any otherfile allocation structure used by the persistent storage media.

[0029] These and other objects and advantages of the invention willbecome apparent from the following more detailed description, when takenin conjunction with the accompanying drawings of illustrativeembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030]FIG. 1 is a block diagram illustrating a device and componentscapable of verification before and during use of the device using thesystem and methods of the present invention;

[0031]FIG. 2 is a flow diagram illustrating the steps for performingverification of the device of FIG. 1;

[0032]FIG. 3 is a flow diagram illustrating the steps performed by thesystem of FIG. 1 for replacing data files that are unverified or containerrors;

[0033]FIG. 4 is a block diagram illustrating the structure of a networkthat may be used with the device of FIG. 1;

[0034]FIG. 5 is a flow diagram illustrating the steps preformed by amonitor in a gaming machine embodiment of FIG. 1; and

[0035]FIG. 6 is a flow diagram illustrating the steps for reading a fileallocation structure or file allocation table of a persistent storagemedia in the device of FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] Referring now to the drawings, like reference numerals denotelike or corresponding parts throughout the drawing figures.

[0037] With reference to FIG. 1, a block diagram illustrating a device10 and components 50 capable of verification before and during use ofthe device 10 using the system and methods of the present invention isshown. The components 50 may comprise, for example, software or datafile components 54, firmware components 64-74, hardware components 60,62, 80, 90, or structural components 130 of the device 10. Thesecomponents include, without limitation, one or more processors 62,persistent storage media 80 and 90, volatile storage media such asrandom access memories (RAMs) 76, read-only memories (ROMs) 77 orelectrically erasable programmable ROMs (EEPROMS) such as basicinput/output systems (BIOS) 64. Components 50 may also include datafiles 54 (which are any collections of data, including executableprograms in binary or script form, and the information those programsoperate upon), device cabinets (housings) 130, cathode ray tubes (CRTs)134, or compact disk read only memory (CDROM) or CD read-write (CR-RW)storage 80. The data files 54 may include data files 100-104, softwareprogram files 92-96, operating system files 98, or file allocationtables or structures 99. Ports 139 may be included with the device 10for connection to diagnostic systems 140 and other input/output devices142. The ports 139 may each comprise a serial port, universal serial bus(USB) port, parallel port or any other type of known port, including awireless port. Preferably, each of the components 50 have embedded orloaded in them identification numbers or strings that can be accessed bythe processor 60, including the processor 60 itself, which are utilizedfor verification as explained below. The data files 54 may use theirfile name as their identification number of string.

[0038] Either within the device 10, or in the diagnostic system 140attachable to the device 10, are executable instructions or a softwareprogram 70 for verification of the components (verification software70), which may itself be one of the components 50 to verify if it isinternal to the device 10. The verification software 70 is may be storedon a persistent storage media such as the hard disk device 90, ROM 77,EEPROM 64, in a complementary metal oxide semiconductor memory (CMOS)72, in safe ram comprising a battery-backed static random access memory(BBRAM) 62, in a flash memory or other type of persistent memory.Preferably, the verification software 70 is stored in a basicinput/output system (BIOS) 64 device or chip. BIOS chips 64 have beenused for storing prior verification software, such as previous versionsof the BIOS+ chip used by Bally Gaming Systems, Inc. of Las Vegas, Nev.in their EVO gaming system. Placing the verification software 70 in theBIOS 64 is advantages because the code in the BIOS 64 is usually thefirst code executed upon boot or start-up of the device 10, making ithard to bypass the verification process.

[0039] Alternatively, the verification software 70 may be stored in afirmware hub (FWH), which may comprise the part of an electronic device10, which may be a computer, that stores BIOS information. Hubtechnology is currently being developed and used by the IntelCorporation of Santa Clara, Calif. Usually, so called north and southbridges link elements of chip sets through a peripheral componentinterconnect (PCI) bus. In the hub architecture, the elements areconnected via an interlink dedicated bus. This is a high-speed bus,currently with twice the bandwidth of the PCI bus. Typically, theinterlink bus operates at 133 MHz in 2× mode. Being 64 bits wide theinterlink provides a bandwidth of 266 MB/sec (2×133.000.000×8 byte). Onesuch hub is known as a firmware hub (FWH). Intel's 82802 FWH storessystem BIOS and video BIOS in a 4 Mbit or 8 Mbit EEPROM or flash EEPROM.

[0040] As another alternative, the persistent storage media that storesthe verification software 70 may be a removable storage unit such as theCD-ROM or CD-RW device 80, a WORM device, a floppy disk device, aremovable type of hard disk device 90, a ZIP disk device, a JAZZ diskdevice, a DVD device, a removable flash memory device, or a hard cardtype of hard disk device 90. However, the database 74 containingverification data used by the verification software 70, described below,is preferably stored either within the device 10 being verified in anon-removable, secure device, such as the BIOS+ 64 shown in FIG. 1, orremotely on a server for networked devices.

[0041] With reference to FIG. 2, a flow diagram illustrating the stepsfor performing verification of the device 10 of FIG. 1 is shown.Beginning at step 200, identification numbers of the components 50 areread and then verified. Each identification number is then searched inthe database 74 to determine whether each identification number isvalid, step 202. The determination may be as simple as checking forwhether the identification number exists in the database. If theidentification number is not found in the database 74, step 204, then atilt condition message is generated in the device 10, step 206, whichmay end operation of the device 10.

[0042] Preferably, digital signatures of the digital contents of atleast the data files 54 and firmware of the components 50 are also usedto perform verification as explained in detail below. In the databaserecord where the identification number was located in the database 74,74, an abbreviated bit string, or encrypted signature, created from thedata file 54 or firmware of the component 50 when the device 10 wasfirst assembled or before the device 10 was deployed, is stored. Theverification software 70 contains instructions that cause the processor60 to read the signature from the database record, step 208. A digitalsignature analysis is performed, step 210. If the data file 54 orfirmware of the component 50 fails an authentication, step 212, then atilt condition message is generated in the device 10, step 206, whichmay end operation of the device 10.

[0043] In the case where a data file 54 comprises one of a plurality ofoperating system files 98, verification of that file 54, in effect,comprises verifying part of an operating system 98.

[0044] The database 70 may comprise a relational database, objectdatabase, or may be stored in XML format, or stored in a number of otherformats that are commonly known. However, in the case where storagespace is limited for the verification system, a flat file structure forthe database 70 may be more desirable, and require less softwareinstructions to read and retrieve information from. The database 70 mayalso comprise an independent system stack of bindings from manufacturersof the components 50, each identification number being verified usingthe binding from the manufacturer of the respective component 50 toverify the component 50. Especially in the context of smaller devices 10such as personal digital assistants (PDAs), such a system stack maycomprise a subset of one or more global component databases containingbindings from manufacturers of the components 50, each binding of thesubset being associated with at least one of the identification numbersof one of the components 50 in the device 10. Providing such a limitedsubset helps control the size of the verification system by controllingthe size of the database 70. Another example of a verification system inwhich it may be desirable to limit the size of the database is one inwhich the database is stored in a personal computer's (PC's)complementary metal oxide semiconductor memory (CMOS) 74, along withother configuration settings for the PC. Storing the database in theCMOS 74 may improve security wherein the PC may be configured such thatonly users with administrative passwords may change the content of theportion of the CMOS 74 containing the database 70.

[0045] Structural components 130, such as cabinets, may contain anelectronic identification chip embedded within them, such as a Dallaschip or an IBUTTON device manufactured by Dallas Semiconductor of DallasTex. IBUTTONs devices allow a unique identifier, placed within asemiconductor or chip, to be placed on a component 50 that may or maynot be electronic, such as a computer or gaming machine cabinet 130. TheIBUTTON is, in effect, a computer chip enclosed in a 16 mm stainlesssteel can. It can be mounted, preferably permanently orsemi-permanently, on or in the structural component 130.

[0046] The searching or matching of each identification number maycomprise matching each identification number based on the type ofcomponent 50 that the identification number identifies. Theidentification number and the type of component are matched in thedatabase in order to verify that the identification number is valid.Each database record in the database 70 contains the type of component50 that the identification number in that record is supposed torepresent. The type of component 50 may be recognized by theverification software either by the location from which theidentification number was read, or by performing a test of eachcomponent 50 to determine its type. For example, in some electronicdevices 10, the processor 60 may always be located at location 0 on thePCI bus or firmware hub of the device 10. Alternatively, by testing thecomponent 50, the verification software 70 may find registers, which mayindicate that the component 50 is a processor 60. Otherwise, theidentification number itself may be formatted to indicate the type ofcomponent 50.

[0047] The reading of the identification numbers and verifying thecomponents 50 may be performed at the time of start-up of the device 10,or periodically during operation of the device 10. Operation of thedevice may be stopped if any one of the identification numbers are notmatched in the database 10 or if the digital contents of a components 50are not authenticated with the corresponding digital signature stored inthe database 74. A tilt condition message is generated by theverification software 70 if any one of the identification numbers is notmatched in the database 74.

[0048] The signatures in the database 74 are also referred to asbindings. When the components 50 are installed before the device 10 isput into operation in the relevant field of use, at least with respectto the components 50 that comprise data files 54 or contain firmware, awell-known hash function, the Secure Hash Function-1 (SHA-1), may beused for authentication. The SHA-1 computes a 160-bit hash value fromthe contents of the data file 54 or firmware. This 160-bit hash value,also called an abbreviated bit string, is then processed to create asignature of the game data using an equally well-known, one-way, privatesignature key technique, the Digital Signature Algorithm (DSA). The DSAuses a private key of a private key/public key pair, and randomly orpseudorandomly generated integers, to produce a 320-bit signature of the160-bit hash value of the data file 54 or firmware contents of thecomponent 50. This signature is stored in the database 74 in addition tothe identification number.

[0049] When the device 10 is in operation in the relevant field of use,to perform a verification of the device 10, the verification softwareexecutes a DSA verification of the data files 54 and firmware of thecomponents 50. Also stored in the database 74 is the public key of theprivate key/public key pair. For each data file 54 and firmware of eachcomponent 54, as part of the DSA verification, the processor 60 andverification software 70 first computes the hash value of the digitalcontents of the component 50 or data file 54 using the SHA-1 algorithm.The verification software 70 contains instructions that cause theprocessor 60 to then processes or authenticate this computed hash valuewith the stored signature, using the DSA signature verificationalgorithm, which also takes, as input, the aforementioned public keystored in the database 74. The verification part of the DSA produces aboolean result (yes or no) as to whether the inputs solve the algorithm.If the algorithm is not solved by the inputs, then an unexpected resultis produced, thereby failing to verify the particular component 50 ordata file 54. A tilt message is generated which triggers a shut-downmechanism to prohibit the loading operation of the device 10 or to stopoperation of the device 10 if verification is performed duringoperation. Otherwise, use of the device 10 is permitted. A detaileddescription of the DSA can be found in the U.S. government's FederalInformation Processing Standards Publication (FIPS) 186-2. Thatpublication describes each step of the DSA signature generation andverification.

[0050] Alternatively, the verification software 70 may use theRivest-Shamir-Adleman (RSA) algorithm to verify the components 50. Usingthe RSA algorithm, a first abbreviated bit string or hash value iscomputed from each component's digital contents and encrypted into adigital signature. The digital signature is stored in the database 74along with the identification number for the component 50. When thedevice is verified, the component 50 is verified by computing a secondabbreviated bit string computed from the component's digital contents.The signature is retrieved from the database 74 by searching thedatabase 74 for the identification number. The signature is decrypted torecover the first abbreviated bit string. The component 50 is thenverified by comparing the second abbreviated bit string with the firstabbreviated bit string. If the first and second abbreviated bit stringsdo not match, then the component 50 is not verified. A tilt message isgenerated which triggers a shut-down mechanism to prohibit the loadingoperation of the device 10 or to stop operation of the device 10 ifverification is performed during operation. Otherwise, use of the device10 is permitted.

[0051] Instead of creating a digital signature for, or signing, eachdata file 54 individually, collections of data files 54 may be signedtogether in order speed up processing. The abbreviated bit strings, hashvalues, or signatures, also called digests, of data files 54 arecollected into a catalog file, and the catalog is signed as describedabove. The verification software 70 identifies each file as being amember of a particular catalog, which can be done by cross referencingthe name of the data file or the identification number, in the database74. For verification, abbreviated bit strings are computed from each ofthe digital files 54, and collected into a catalog, which is itselfsigned, and then verified using DSA or RSA verification techniques asdescribed above. Thus, the catalog itself becomes a signed data file 54that is verified, just as if it was an individual data file 54.

[0052] With reference to FIG. 3, a flow diagram illustrating the stepsperformed by the system of FIG. 1 for replacing data files 54 that areunverified or contain errors is shown. In some cases, it may bedesirable to nevertheless allow operation of a device 10 even though adata file 54 failed verification. For example, that data file 54 maycontain an error caused by a number of events, such as a bad sector onthe hard disk 90, which in turn caused the failed verification of thatdata file 54. In that example, the failed verification is evidently notdue to tampering of the device 10 as the system of the present inventionis generally designed to prevent. Still, operation of the device 10 isnot desirable unless and until the error in the data file 54 iscorrected. When the data file 54 is stored in alterable media 90,correcting such an error may be as simple as replacing the file 54.Along with the identification number, and encrypted signature orabbreviated bit string, a valid replacement data file 44 may also bestored in the database 74. Starting with step 300, the verificationsoftware 70 finds an invalid data file 54 as described above withreference to FIG. 2. The verification software 70 may contain logic thatexamines the failed verification to determine whether the cause of theinvalid data file 54 is simply an error in the data file 54, and nottampering, step 302. Such logic may comprise, for example, fuzzy logic,which uses historical data to determine if the circumstances surroundingthe failed verification most likely indicate a simple error instead oftampering. A number of factors may be used by the verification software70 to make such a determination. For example, determination may be basedon the number of data files 54 or components that fail verification.Historical data in the fuzzy logic may show that having a certainpercentage of failed verifications may indicate tampering of the device10. This may indicate a deceptive replacement of the hard disk 90 in thedevice 10 for example. If the verification software so indicates thattampering of the device 10 was most likely to have occurred, step 304,then a tilt message is generated, step 306. Otherwise, a replacementdata file 54 is pulled from the database 74 to replace the data file 54that failed the validation, step 308.

[0053] Alternatively to storing the replacement, or update, files in thedatabase 74, the update files may be located in the CDROM or CD-RWdevice 80 as indicated at 82. Storing the update files 82 on the CDdevice 80 is preferable if the data files 54 are large, while thedatabase itself 74 remains stored securely in the BIOS+ 64. The updatefiles 82 are organized in a large update file database for easy indexingby identification number.

[0054] With reference to FIG. 4, a block diagram illustrating thestructure of a network that may be used with the device of FIG. 1 isshown. In one embodiment, the database 74 is remote from the device 10,or a plurality of devices 10, wherein verification is performed over anetwork 400 connecting a database server 402 containing the database 74with the device 10. The database 74 is stored in a persistent storagemedia 490 inside or connected to the database server 402. The devicetransmits the identification numbers for each of the components 50(FIG. 1) to the database server 402. The database server 402 thenperforms the step of matching using its own version of the verificationsoftware 70 described herein. For example, the device 10 may be apersonal computer (PC), with verification being performed before atransaction is allowed on a network server 404. A prime example of sucha system is one set up for performing banking transactions with thenetwork server 404 owned or operated by a bank. In such a system, a bankmay only allow trusted transactions using an authorized PC 10 whosebindings for all of the components 50 and banking transaction software(92 in FIG. 1) have been recorded in the database 74. The database maybe either located on the bank's network server 404, or the remotenetwork server 402. Once all of the components have been verified, thebank's network server 402 then allows transactions to take place usingthe PC 10.

[0055] In another example, the device 10 comprises a gaming machine 10,wherein the verification of the gaming machine 10 is performed beforegame play is allowed on the gaming machine. The database 74 may eitherbe located in a secure location in the gaming machine 10, such as a ROMdevice 77 enclosed in a lock box within the gaming machine 10, orremotely from the gaming machine 10 so that the gaming machine 10connects to the network server 402 containing the database 74 over thenetwork 400. As with the banking personal computer 10 described above,the components 50 of the gaming machine 10 are verified at the networkserver 402 after the gaming machine 10 transmits the identificationnumbers, hash values, etc., to the network server 402.

[0056] Another aspect of the present invention is a method and systemfor recording event messages in a gaming machine 10. The device 10 maycomprise a gaming machine 10, which contains a monitor 108 formonitoring one or more system events being processed by the gamingmachine 10. The monitor 108 may comprise a set of executableinstructions, or a software program, which may be located in a varietyof places within the gaming machine 10 ready for loading into RAM 76 forexecution by the processor during operation of the gaming machine 10.For example, the monitor 108 may be stored on the hard disk 90, ROM 77or BBRAM 62. Preferably, the operating system 98 of the gaming machine10 is event driven. In an event driven system or device 10, applications92 and components 50 respond to input from the user (mouse movement,keystrokes, menu choices, etc.) and messages from other applications 92and components 50. This is in contrast to, for example, a batchoperation that continuously processes the next item from a group ofinstructions. The monitor 108 comprises an event management system,which comprises software or firmware that monitors the applications 92,operating system 98 processes and other components 50 of the device.Alternatively, at least parts of the monitor 108 may be located on aremote server 402, workstation or other network devices.

[0057] With reference to FIG. 5, a flow diagram illustrating the stepspreformed by the monitor 108 and gaming machine 10 is shown. The monitor108, which may alternatively comprise both hardware and softwarecomponents 50 in the device 10. such as its own processor 60 and eventmanagement software 92, monitors routine and non-routine events or eventmessages generated in the gaming device, step 500. As an example, a coininsertion into the gaming machine 10 will trigger a correspondingroutine coin-in event message that triggers components 50 to operateand/or software instructions to execute. Similarly, an exception faultor divide by zero condition will trigger a non-routine or error eventmessage to be generated. These event messages can be generally referredto as system events or event messages.

[0058] Either included within the monitor 108, or separately but inclose coordination with the monitor 108, is a detector 110 for detectingselected system events of the one or more system events so that they maybe recorded, step 502. The gaming machine 10, or the remote server 402monitoring the gaming machine 10, stores the event message for thedetected system event in a log file 104 on a persistent storage devicesuch as the hard disk 90 or a persistent storage media 490 on the remoteserver 402.

[0059] In the step of detecting, step 502, each monitored system eventis of a certain type, which, for reference purposes, can be referred toas a system event type. The detector 110 selects the selected systemevent based on the system event type for the selected system event. Thesystem event type may, for example, comprise a code in the event messagethat indicates a category of events that occur in the gaming machine 10that the system event belongs to or from which the event message wasgenerated. For example, the previously mentioned coin-in, exceptionfault and divide by zero system events are each so identified with thesystem event type. In step 502, the detector 110 selects the selectedsystem event by comparing the system event type for each monitoredsystem event to a list of system event types, and selecting one of themonitored system events for the selected system event if the systemevent type for the selected one monitored system event matches one ofthe system event types in the list. Each system event is monitored andas the detector selects a plurality of system events based on theirtypes, the system event messages for each selected system event isstored in the log file 104 on the hard disk 90. The list may be storedin an index or lookup file 112 on the hard disk 90. The lookup file maycomprise a database file 112 which may be relational, object based or inXML format for example.

[0060] A buffer region of the RAM 76 may be set aside for buffering aplurality of the monitored system events, wherein the step of storing,step 503, comprises storing one or more of the buffered system events inthe log file 104 each time one of the system event types for storing isdetected in step 502 by the detector 110. Preferably, the buffer in RAM76 should be large enough so that at least the last 1000 system eventsmay be stored in the buffer, and then written to the log file 104 if aselected system event is detected and stored. The buffer in RAM 76 isthus operated as a first-in-first-out stack of system event messages.

[0061] Other digital contents of memories 62 and 76, or components 50 inthe gaming machine 10 may be stored upon detection of a selected systemevent. For example, it may be desirable to store the entire contents ofa memory of a component 50, selected contents of a memory of a component50, or selected or entire values for registers of a processor component60 of the gaming machine 10. For example, if a selected system event isa memory protection exception error, then it may be desirable to storeat least the contents of the protected memory in RAM 76 that wasviolated and memory allocation tables for the offending application(s)that caused the error. Even if the memory portion in which theprotection exception error occurred comprises a safe RAM orbattery-backed memory device 62, it nevertheless still may be desirableto store the contents of that memory 62 in case other applicationsshould further modify the memory 62.

[0062] With reference to FIG. 6, a flow diagram illustrating the stepsfor reading a file allocation structure or file allocation table 99 of apersistent storage media is shown. As another aspect of the presentinvention, it is desirable to perform operations on data files 54 storedon the persistent storage media, such as verification operations, beforeor without the need for the operating system 98 for an electronic device10 is loaded. Typically, the operating system 98 must be loaded, andstarted or booted, in order to perform file access operations onpersistent the storage media 90. This is because the operating systemusually exclusively contains the file access system used to read thefile allocation structure 99 stored on the storage media 90. However, insome devices 10, it would be desirable to validate data files 54 on thepersistent storage media 90 before booting the operating system 99 for,among other reasons, security purposes.

[0063] In that regard, the system of the present invention has a fileallocation reader 76 stored in the BIOS or FWH 64. This makes accessingfiles stored in the persistent storage media 90 possible in the absenceof a running operating system 98. The processor 60 may access the fileallocation reader 76 stored in the BIOS, step 600, to open the fileallocation structure 99 on the persistent storage media 90 and to readit, step 602. The file allocation reader 76 is a computer program whichcomprises a set of executable instructions for processing the fileallocation structure such as that used by the operating system 98. Forfaster access, the processor 60 may move the contents of the fileallocation structure 99 into a RAM 76. The processor 60 may then processthe file allocation structure 604 to provide access to files stored inthe storage device.

[0064] An example of such an application that may benefit from this newfunctionality in the BIOS is the verification software 70 describedabove for verifying software components or data files 54 on thepersistent storage media 90. In that case, operating system files 98 maybe verified before loading or booting, or before any software program 92is run from the persistent storage media 90. This makes the verificationsoftware 70 completely independent of data files 54 stored on thepersistent storage media 90 which are being verified.

[0065] As described above, verifying the data files 54 may compriseverifying each data 54 file by retrieving a first abbreviated bit stringcomputed from the file from the database 74, computing a secondabbreviated bit string from the data file 54, and verifying the file byauthenticating the second abbreviated bit string using the firstabbreviated bit string. As described above, the database of signaturesor abbreviated bit strings 74 may be stored in the BIOS 64 as well,wherein the verification software uses DSA or RSA to verify each datafile 54 against the corresponding signature or abbreviated bit stringstored in the database 74. The file allocation reader 76 in the BIOS orFWH 64 may be configured to read a 32-bit based file allocation table99, a 16-bit based file allocation table 99, a WINDOWS NT file systemstructure 99, or any other file allocation structures 99 used by thepersistent storage media 90.

[0066] It will be apparent from the foregoing that, while particularforms of the invention have been illustrated and described, variousmodifications can be made without departing from the spirit and scope ofthe invention. Accordingly, it is not intended that the invention belimited, except as by the appended claims.

What is claimed is:
 1. A method for verifying a device, the devicehaving one or more components, comprising: (a) reading an identificationnumber of one or more components of the device, and (b) verifying thateach identification number is valid.
 2. The method of claim 1, whereinthe step of verifying comprises matching each identification number in adatabase to determine whether each identification number is valid. 3.The method of claim 2, wherein each of the one or more components isassociated with a type of component.
 4. The method of claim 3, whereinthe step of matching comprises matching each identification number basedon the type of component that the identification number identifies suchthat the identification number and the type of component is matched inthe database in order to verify that the identification number is valid.5. The method of claim 1, wherein each of the one or more components isselected from the group consisting of: a software component, a firmwarecomponent, a hardware component, and a structural component.
 6. Themethod of claim 1, wherein at least one of the components comprises aprocessor.
 7. The method of claim 1, wherein at least one of thecomponents comprises a persistent storage media.
 8. The method of claim1, wherein at least one of the components comprises a ROM.
 9. The methodof claim 8, wherein the ROM comprises an EPROM.
 10. The method of claim1, wherein at least one of the components comprises a data file.
 11. Themethod of claim 10, wherein the data file comprises a software programfile.
 12. The method of claim 10, wherein the data file comprises one ofa plurality of operating system files, such that the step of verifyingcomprises verifying at least part of an operating system.
 13. The methodof claim 10, comprising replacing the file if it is not valid.
 14. Themethod of claim 2, comprising stopping operation of the device if anyone of the identification numbers is not matched in the database. 15.The method of claim 14, wherein the steps of reading and verifying areperformed at the time of start-up of the device.
 16. The method of claim14, wherein the steps of reading and verifying are performedperiodically during operation of the device.
 17. The method of claim 2,comprising generating a tilt condition message if any one of theidentification numbers is not matched in the database.
 18. The method ofclaim 17, wherein the database is remote from the device, the step ofverifying being performed over a network connecting a database servercontaining the database with the device, the device transmitting theidentification numbers for each of the components to the databaseserver, the database server performing the step of matching.
 19. Themethod of claim 18, wherein the device is a personal computer, the stepof verifying being performed before a transaction is allowed on anetwork server.
 20. The method of claim 19, wherein the network servercontains the database server.
 21. The method of claim 2, wherein thedevice is a banking terminal, the step of verifying being performedbefore a banking transaction is allowed.
 22. The method of claim 2,wherein the device is a gaming machine, the step of verifying beingperformed before game play is allowed on the gaming machine.
 23. Themethod of claim 2, wherein the database comprises a relational database.24. The method of claim 2, wherein the database comprises an objectdatabase.
 25. The method of claim 2, wherein the database is in XMLformat.
 26. The method of claim 2, wherein the database comprises anindependent system stack of bindings from manufacturers of thecomponents, each identification number being verified using the bindingfrom the manufacturer of the respective component to verify thecomponent.
 27. The method of claim 26, wherein system stack comprises asubset of one or more global component databases containing bindingsfrom manufacturers of the components, each binding of the subset beingassociated with at least one of the identification numbers.
 28. Themethod of claim 2, wherein the database is stored in a CMOS memory. 29.The method of claim 2, wherein the database is stored in a BIOS.
 30. Asystem for verifying a device; comprising: (a) one or more components;and (b) a processor for reading an identification number of each of theone or more components and for verifying that each identification numberis valid.
 31. The system of claim 30, comprising one or more sets ofexecutable instructions that are executed by the processor for readingand verifying the identification numbers.
 32. The system of claim 31,comprising a persistent storage media.
 33. The system of claim 32,wherein at least one of the one or more sets of executable instructionsare stored in the persistent storage media.
 34. The system of claim 32,wherein the persistent storage media is a basic input-output chip. 35.The system of claim 32, wherein the persistent storage media is afirmware hub.
 36. The system of claim 32, wherein the persistent storagemedia is a hard disk device.
 37. The system of claim 32, wherein thepersistent storage media is a removable storage unit selected from thegroup consisting of: a CD-ROM reader, a WORM device, a CD-RW device, afloppy disk device, a removable hard disk device, a ZIP disk device, aJAZZ disk device, a DVD device, a removable flash memory device, and ahard card device.
 38. The system of claim 32, wherein the persistentstorage media is a flash memory.
 39. The system of claim 30, furthercomprising a database, wherein the processor is further for verifyingeach identification number by matching each identification number in thedatabase to determine whether each identification number is valid. 40.The system of claim 39, wherein each of the one or more components isassociated with a type of component.
 41. The system of claim 40, whereinthe processor is for matching each identification number based on thetype of component that the identification number identifies such thatthe identification number and the type of component is matched in thedatabase in order to verify that the identification number is valid. 42.The system of claim 30, wherein each of the one or more components isselected from the group consisting of: a software component, a firmwarecomponent, a hardware component, and a structural component.
 43. Thesystem of claim 30, wherein at least one of the components comprises theprocessor.
 44. The system of claim 30, wherein at least one of thecomponents comprises a ROM.
 45. The system of claim 44, wherein the ROMcomprises an EPROM.
 46. The system of claim 30, wherein at least one ofthe components comprises a data file.
 47. The system of claim 46,wherein the data file comprises a software program file.
 48. The systemof claim 46, wherein the data file comprises one of a plurality ofoperating system files comprising portions of an operating system. 49.The system of claim 46, wherein the processor is further for replacingthe data file if it is not valid.
 50. The system of claim 39, whereinthe processor is further for stopping operation of the device if any oneof the identification numbers is not matched in the database.
 51. Thesystem of claim 30, wherein the processor is for reading and verifyingthe identification numbers at the time of start-up of the device. 52.The system of claim 30, wherein the processor is for reading andverifying the identification numbers periodically during operation ofthe device.
 53. The system of claim 39, wherein the processor is furtherfor generating a tilt condition message if any one of the identificationnumbers is not matched in the database.
 54. The system of claim 39,wherein the device is capable of connecting to a network, wherein thedatabase is stored on a server that is remote from the device, theprocessor for verifying the identification numbers over the network, theprocessor further for transmitting the identification numbers to theserver to match the identification numbers in the database.
 55. Thesystem of claim 54, wherein the device is a personal computer containingthe components for verifying before a transaction is allowed on theserver.
 56. The system of claim 30, wherein the device is a bankingterminal containing the components for verifying before a bankingtransaction is allowed.
 57. The system of claim 30, wherein the deviceis a gaming machine containing the components for verifying before gameplay is allowed on the gaming machine.
 58. The system of claim 39,wherein database comprises an independent system stack of bindings frommanufacturers of the components, the processor further for verifyingeach identification number using the binding from the manufacturer ofthe respective component to verify the component.
 59. The system ofclaim 58, wherein system stack comprises a subset of one or more globalcomponent databases containing bindings from manufacturers of thecomponents, each binding of the subset being associated with at leastone of the identification numbers.
 60. The system of claim 39,comprising a CMOS memory, wherein the database is stored in the CMOSmemory.
 61. The system of claim 39, comprising a BIOS, wherein thedatabase is stored in the BIOS.
 62. A method for verifying a devicecontaining one or more data sets; comprising: (a) retrieving a firstabbreviated bit string computed from each data set from a database; (b)computing a second abbreviated bit string from each of the one or moredata sets; and (c) verifying each data set by authenticating the secondabbreviated bit string computed from the data set using the firstabbreviated bit string.
 63. The method of claim 62, wherein the step ofverifying is performed using the Digital Signature Algorithm toauthenticate the second abbreviated bit string using the firstabbreviated bit string.
 64. The method of claim 62, wherein the step ofverifying is performed using the Rivest-Shamir-Adleman algorithm tocompare the second abbreviated bit string with the first abbreviated bitstring, wherein each first abbreviated bit string is stored in anencrypted signature in the database for decrypting and comparing to thesecond abbreviated bit string.
 65. The method of claim 62, wherein atleast one of the data sets comprises a file.
 66. The method of claim 65,comprising replacing the file if it is not verified.
 67. The method ofclaim 62, wherein the database comprises a relational database.
 68. Themethod of claim 62, wherein the database comprises an object database.69. The method of claim 62, wherein the database is in flat-file format.70. The method of claim 62, wherein the database is in XML format. 71.The method of claim 62, wherein the database is stored in a CMOS memory.72. The method of claim 62, wherein the database comprises anindependent system stack of first abbreviated bit strings frommanufacturers of the data sets, each second abbreviated bit string beingverified using a first abbreviated bit string from the respectivemanufacturer of the respective data set to verify the data set.
 73. Themethod of claim 72, wherein the system stack comprises a subset of oneor more global databases containing first abbreviated bit strings frommanufacturers of the data sets, each first abbreviated bit string of thesubset being associated with at least one of the data sets.
 74. A systemfor verifying a device; comprising: (a) one or more data sets; (a) adatabase containing a first abbreviated bit string computed from each ofthe one or more data sets; and (b) a processor for computing a secondabbreviated bit string from each of the one or more data sets, and forverifying each data set by authenticating the second abbreviated bitstring computed from the data set using the first abbreviated bitstring.
 75. The system of claim 74, comprising a set of executableinstructions for using the Digital Signature Algorithm forauthenticating the second abbreviated bit string using the computedfirst abbreviated bit string.
 76. The system of claim 74, comprising aset of executable instructions for using the Rivest-Shamir-Adlemanalgorithm to verify the second abbreviated bit string by comparing thesecond abbreviated bit string with the first abbreviated bit string,wherein each first abbreviated bit string is stored in an encryptedsignature in the database, each signature capable of being decrypted andcompared to the respective second abbreviated bit string.
 77. The systemof claim 74, wherein the database comprises a relational database. 78.The system of claim 74, wherein the database comprises an objectdatabase.
 79. The system of claim 74, wherein the database is inflat-file format.
 80. The system of claim 74, wherein the database is inXML format.
 81. The system of claim 74, wherein at least one of the datasets comprises a file.
 82. The system of claim 81, wherein the processoris further for replacing the file if it is not verified.
 83. The systemof claim 74, comprising a CMOS memory, wherein the database is stored inthe CMOS memory.
 84. The method of claim 74, wherein the databasecomprises an independent system stack of first abbreviated bit stringsfrom manufacturers of the data sets, the processor for verifying eachsecond abbreviated bit using the first abbreviated bit string from themanufacturer of the respective data set to verify the data set.
 85. Themethod of claim 84, wherein the system stack comprises a subset of oneor more global databases containing first abbreviated bit strings frommanufacturers of the data sets, each first abbreviated bit string of thesubset being associated with at least one of the data sets.
 86. A methodfor recording event messages in a gaming machine; comprising: (a)monitoring one or more system events being processed by the gamingmachine; (b) detecting a selected one of the one or more system eventsfor recording; and (c) storing an event message for the detected systemevent in a log file.
 87. The method of claim 87, wherein each monitoredsystem event has a system event type.
 88. The method of claim 87,wherein the step of detecting comprises selecting the selected systemevent based on the system event type for the selected system event. 89.The method of claim 87, wherein the step of selecting comprisescomparing the system event type for each monitored system event to alist of system event types, and selecting one of the monitored systemevents for the selected system event if the system event type for theselected one monitored system event matches one of the system eventtypes in the list.
 90. The method of claim 89, wherein the list isstored in a lookup file on a persistent media in the gaming machine. 91.The method of claim 90, wherein the lookup file comprises a databasefile.
 92. The method of claim 86, wherein the log file is stored on apersistent storage media in the gaming machine.
 93. The method of claim86, wherein the log file is in XML format.
 94. The method of claim 90,wherein the lookup file is in XML format.
 95. The method of claim 86,wherein the step of detecting comprises detecting a plurality ofselected system events.
 96. The method of claim 95, comprising bufferinga plurality of the monitored system events, wherein the step of storingcomprises storing one or more of the buffered system events in the logfile with the selected one of the system events.
 97. The method of claim86, the step of storing further comprising storing the contents of amemory after the selected one of the one or more system events isdetected.
 98. The method of claim 97, wherein the memory comprises asafe ram device.
 99. The method of claim 86, the step of storing furthercomprising storing the contents of a register of a processor after theselected one of the one or more system events is detected.
 100. A systemfor recording event messages in a gaming machine; comprising: (a) asystem monitor for monitoring one or more system events being processedby the gaming machine; (b) a detector for selecting one of the one ormore system events for recording; and (c) a storage device for storingan event message for the detected system event in a log file.
 101. Thesystem of claim 100, wherein each monitored system event has a systemevent type.
 102. The system of claim 101, wherein the detector is forselecting the selected system event based on the system event type. 103.The system of claim 101, wherein detector is for selecting the selectedsystem event by comparing the system event type for each monitoredsystem event to a list of system event types, and for selecting one ofthe monitored system events as the selected system event if the systemevent type for the selected one monitored system event matches one ofthe system event types in the list.
 104. The system of claim 103,wherein the list is stored in a lookup file on a persistent storagemedia in the gaming machine.
 105. The system of claim 104, wherein thelookup file comprises a database file.
 106. The system of claim 100,wherein the storage device comprises a persistent storage media. 107.The system of claim 100, wherein the log file is in XML format.
 108. Thesystem of claim 104, wherein the lookup file is in XML format.
 109. Thesystem of claim 100, wherein the detector is for detecting a pluralityof selected system events.
 110. The system of claim 106, comprising abuffer for buffering a plurality of the monitored system events, whereinthe persistent storage media is for storing one or more of the bufferedsystem events in the log file with the selected one of the systemevents.
 111. The system of claim 100, wherein the detector comprises aportion of the monitor.
 112. The system of claim 100, wherein themonitor is a software program comprising a set of executableinstructions.
 113. The system of claim 100, the storage device furtherfor storing the contents of a memory after the selected one of the oneor more system events is detected.
 114. The system of claim 113, whereinthe memory comprises a safe ram device.
 115. The system of claim 100,the storage device further for storing the contents of a register of aprocessor after the selected one of the one or more system events isdetected.
 116. In a basic input/output system, a method for accessingfiles stored in a storage device, comprising: (a) opening a fileallocation structure in a storage device; (b) reading the fileallocation structure; and (c) processing the file allocation structureto provide access to files stored in the storage device.
 117. The methodof claim 116, wherein the basic input/output system comprises asolid-state storage device.
 118. The method of claim 117, wherein thesolid-state storage device comprises a basic input/output system chip.119. The method of claim 116, wherein the basic input/output systemcomprises a firmware hub.
 120. The method of claim 116, wherein the stepof processing comprises accessing the files stored in the storage deviceusing a computer program stored in the basic input/output system, thecomputer program comprising a set of executable instructions forprocessing the file allocation structure.
 121. The method of claim 116,wherein the step of processing comprises verifying the files stored onthe storage device.
 122. The method of claim 116, wherein the step ofverifying comprises verifying each file by retrieving a firstabbreviated bit string computed from the file, computing a secondabbreviated bit string from the file, and verifying the file byauthenticating the second abbreviated bit string using the firstabbreviated bit string.
 123. The method of claim 122, wherein the stepof authenticating comprises authenticating the second abbreviated bitstring using the first abbreviated bit string using the DigitalSignature Algorithm.
 124. The method of claim 122, wherein the step ofauthenticating comprises authenticating the second abbreviated bitstring using the first abbreviated bit string using theRivest-Shamir-Adleman algorithm.
 125. A basic input/output system,comprising: (a) a first storage device; (b) a set of basic input/outputdata set stored in the first storage device; and (c) a file allocationreader stored in the first storage device for processing a fileallocation structure to provide access to files stored in a secondstorage device.
 126. The system of claim 125, wherein the first storagedevice comprises a solid-state storage device.
 127. The system of claim127, wherein the solid-state storage device comprises a basicinput/output system chip.
 128. The system of claim 125, wherein thebasic input/output system comprises a firmware hub.
 129. The system ofclaim 125, further comprising a set of executable instructions stored inthe first storage device, the executable instructions comprising acomputer program for accessing the files stored in the second storagedevice using the file allocation reader to read the file allocationstructure.
 130. The system of claim 129, wherein the computer program isfor verifying each file stored in the second storage device.
 131. Thesystem of claim 130, wherein the computer program is for verifying eachfile by retrieving a first abbreviated bit string computed from the filefrom a database, computing a second abbreviated bit string from thefile, and verifying the file by authenticating the second abbreviatedbit string using the first abbreviated bit string.
 132. The system ofclaim 131, wherein the computer program is for authenticating the secondabbreviated bit string using the first abbreviated bit string using theDigital Signature Algorithm.
 133. The system of claim 131, wherein thecomputer program is for authenticating the second abbreviated bit stringusing the first abbreviated bit string using the Rivest-Shamir-Adlemanalgorithm.
 134. The system of claim 125, wherein the allocationstructure is a file allocation table.
 135. The system of claim 134,wherein the file allocation table is 32-bit based.
 136. The system ofclaim 134, wherein the file allocation table is 16-bit based.
 137. Thesystem of claim 125, wherein the allocation structure is a WINDOWS NTfile system.